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DETAILED ACTION 

Claims 1-19, 23-25, 30-33, 36, 39-47 are pending. 
Claims 21-22, 26-29 and 34-35 were previously cancelled. 
Claims 20 and 37-38 are cancelled in response filed 1 1/12/08. 
Claims 42-47 are newly added claims. 

Response to Arguments 

Applicant's arguments with respect to claims above have been considered but are moot in 
view of the new ground(s) of rejection, as necessitated by the substantial amendments, more 
specifically, in view of the wireless device and/or system. 

In response filed, applicant also argues in substance that: 

a. None of Liou, Dalrymple or Handley teaches a single message from a wireless 
terminal that includes the components of the first media playback invite request of claim 
1 (remarks, pg. 14). 

In response to argument [a], Examiner respectfully disagrees. 
Independent claim 1, in part, recites: 
A method comprising: 

receiving a first media playback invite request initiated by a host wireless terminal, the first media 
playback invite request including: 

information sufficient to identify at least one guest wireless terminal, 
an identification of a pre-existing playable media file, and 

a playback option enabling the guest terminal to request different types of playback 
actions in connection with playback of the identified media file; 
transmitting a second media playback... 
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The functionalities and/or processes as recited above are typical processes of a SIP 
protocol. 

Dalrymple explicitly discloses the usage of SIP protocol for inviting the other computers 
to begin a playback session of a media file in synchronization, e.g. fig. 2 and col. col. 3 L50 to 
col. 4 L46, which are reproduced herein. 
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One of ordinary skilled in the art can clearly see the similarities between the features of 
SIP protocol used to establish a connection between users and the applicant's claimed steps. 
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The SIP invite request typically contains a session description, written in SDP (RFC 
2327) format that provides the called party enough information to join the session, e.g. SEE 
RFC 2543, pg. 14 [1.4.4]. 

More specifically, the SDP provides the following information to the callee and/or in an 
Invite message: 

• Session name and purpose 

• Time the session is active 

• The media comprising the session 

• Information to receive those media, etc. 

A session description consists of a session-level description and optionally several media 
level descriptions, wherein the media description includes media name, title, etc., See RFC 
2327 or Handley, [5], [5.1], [6]: SDP specification, reproduced herein. 

"...A session description consists of a session-level description 
(details that apply to the whole session and all media streams) and 
optionally several media-level descriptions (details that apply onto 
to a single media stream). 

An announcement consists of a session-level section followed by zero 
or more media-level sections. The session-level part starts with a 
"v: 1 line and continues to the first media-level section. The media 
description starts with an "m:' line and continues to the next media 
description or end of the whole session description. In general, 
session-level values are the default for all media unless overridden 
by an equivalent media-level value. 

When SDP is conveyed by SAP, only one session description is allowed 
per packet. When SDP is conveyed by other means, many SDP session 
descriptions may be concatenated together (the "v:' line indicating 
the start of a session description terminates the previous 
description). Some lines in each description are required and some 
are optional but all must appear in exactly the order given here (the 
fixed order greatly enhances error detection and allows for a simple 
parser). Optional items are marked with a "*' 



Session description 
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v= (protocol version) 

o= (owner/creator and session identifier). 

s: (session name) 

i=* (session information) 

Handley & Jacobson Standards Track [Page 7] 
RFC 2327 SDP April 1998 

u=* (URI of description) 

e=* (email address) 

p=* (phone number) 

c:* (connection information - not required if included in all media) 
b=* (bandwidth information) 

One or more time descriptions (see below) 

z:* (time zone adjustments) 

k=* (encryption key) 

a=* (zero or more session attribute lines) 

Zero or more media descriptions (see below) 

Time description 

t: (time the session is active) 

r=* (zero or more repeat times) 

Media description 

m= (media name and transport address) 
i=* (media title) 

c:* (connection information - optional if included at session-level) 

b=* (bandwidth information) 

k=* (encryption key) 

a=* (zero or more media attribute lines) 



An example SDP description is, e.g. See Handley, pg. 7-8: 



v=0 

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 
s=SDP Seminar 

i:A Seminar on the session description protocol 
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp. 03.ps 
e=mjh@isi.edu (Mark Handley) 
c=IN IP4 224.2.17.12/127 
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Handley & Jacobson Standards Track [Page 8] 
RFC 2327 SDP April 1998 

1=2873397496 2873404696 
a=recvonly 

m:audio 49170 RTP/AVP 0 
m: video 51372 RTP/AVP 31 
m:application 32416 udp wb 
a:orient:portrait 



Handley, atpg. 17-18, further discloses: 

Attributes 

a= 
a=: 

Attributes are the primary means for extending SDP. Attributes may 
be defined to be used as "session-level" attributes, "media-level" 
attributes, or both. 

A media description may have any number of attributes ("a:" fields) 
which are media specific. These are referred to as "media-level" 
attributes and add information about the media stream. Attribute 
fields can also be added before the first media field; these 
"session-level" attributes convey additional information that applies 
to the conference as a whole rather than to individual media; an 
example might be the conference's floor control policy. 

Attribute fields may be of two forms: 

o property attributes. A property attribute is simply of the form 
"a:". These are binary attributes, and the presence of the 
attribute conveys that the attribute is a property of the session. 
An example might be "a:recvonly". 

o value attributes. A value attribute is of the form 
"a::". An example might be that a whiteboard 
could have the value attribute "a:orient:landscape" 

Attribute interpretation depends on the media tool being invoked. 
Thus receivers of session descriptions should be configurable in 
their interpretation of announcements in general and of attributes in 
particular. 



And, at pg. 22-23, Handley further discloses: 



a=recvonly 
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This specifies that the tools should be started in receive-only 
mode where applicable. It can be either a session or media 
attribute, and is not dependent on charset. 

a:sendrecv 

This specifies that the tools should be started in send and 
receive mode. This is necessary for interactive conferences with 
tools such as wb which defaults to receive only mode. It can be 
either a session or media attribute, and is not dependent on 
charset. 

a:sendonly 

This specifies that the tools should be started in send-only 
mode. An example may be where a different unicast address is to 
be used for a traffic destination than for a traffic source. In 
such a case, two media descriptions may be use, one sendonly and 
one recvonly. It can be either a session or media attribute, but 
would normally only be used as a media attribute, and is not 
dependent on charset. 

a:orient: 

Normally this is only used in a whiteboard media specification. 
It specifies the orientation of a the whiteboard on the screen. 
It is a media attribute. Permitted values are "portrait', 
"landscape' and "seascape' (upside down landscape). It is not 
dependent on charset 



Clearly, the "a" attribute option, which is media specific, included within the SDP 
description, enables the callee to request different types of playback actions. In other words, it 
enables the callee to receive data as well send data, e.g. request including actions, and/or vice- 
versa. 



For example: a:sendrecv 

This specifies that the tools should be started in send and 
receive mode. This is necessary for interactive conferences with 
tools such as wb which defaults to receive only mode. It can be 
either a session or media attribute, and is not dependent on 
charset. 
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This option enables the computers to send and receive data and/or information. In other 
words, it enables the callee computer to send the different types of actions associated with a tool. 

If a:recvonly, then the callee computer may not be able to send the different types of 
actions, because the option is set to recv only. 

In response filed, applicant asserts that "For example... however, the "a=sendrecv" field 
described by Handley at pg. 23 is not a playback option enabling the guest terminal to request 
different types of playback actions in connection with playback of a pre-existing playable media 
file (remarks, pg. 14)". 

Examiner disagrees for the reasons set forth above. 

In the written description, e.g. pg. 7 [25], applicant discloses: 

"...In one variation, invite request comprises various fields, including guest user id, session id, media file 
id, host user id, playback options, playback scheduling, and a free text string of other media type that explains the 
invitation to the guest users. Playback options give specific guest users permission to request different types of 
actions during playback session..." 

In other words, the playback option allows and/or enables the guest users to request 
different types of actions. 

The "a=sendrecv" field in Handley is a playback option that is associated with the 
playback and/or synchronization of media and is a media specific, which enables and/or allows 
the callee computer to send and receive data including requesting different types of actions. One 
of the "a=..." field denies the guest users to request different types of actions, i.e. denies the 
users to send any data or requests. 

Furthermore, applicant acknowledges that "Instead, Handley indicates that... should be 
started in "send and receive mode". Clearly, the send and receive mode enables and/or gives the 
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callee the permissions to receive and send the data. The data can include requesting different 
types of action. 

Applicant also asserts "Handley gives no indication that it would be a request related to 
playback of pre-existing media file", e.g. pg. 15. 

The SDP set forth above identifies the media file. Obviously, the media file is pre- 
existing at some location. Moreover, LIOU discloses the pre-existing media file and requesting 
different types of actions in connection with the media file, e.g. fig. 10 and pg. 18 line 4 to pg. 19 
line 13. 

As per "wireless terminals" and/or "wireless transmission", the arguments are moot in 
view of Vilander. See the detailed rejection. 



Claim Rejections - 35 USC 8 112 

The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

1. Claims 1-19, 23-25, 30-33, 36 and 39-47 are rejected under 35 U.S.C. 112, first 
paragraph, as failing to comply with the written description requirement. 
Independent claim 1 recites: 

A method, comprising. . . 

transmitting a second media playback invite request received to the guest wireless terminal 
subsequent to receipt of the first media playback invite request, wherein the second media playback invite 
request includes the playback option; 

relaying a media playback accept response from the guest wireless terminal to the host wireless 

terminal; 

distributing a start playback request from the host wireless terminal to the guest wireless terminal, 
wherein the start playback request directs the guest wireless terminal to begin a playback session of the 
identified media file in synchronization with a beginning of the playback session at the host wireless 
terminal; 
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receiving an action request from the guest wireless terminal, wherein the action request includes 
the playback option; and 

sending the playback option received from the guest wireless terminal to the host wireless 
terminal. 



In the written description, applicant discloses: 

"...In one variation, invite request comprises various fields, including guest user id, session id, media file 
id, host user id, playback options, playback scheduling, and a free text string of other media type that explains the 
invitation to the guest users. Playback options give specific guest users permission to request different types of 
actions during playback session..." (pg. 7 [25]). 

"During the playback session, any of the active users can request a playback action. In order to do so, 
an active user sends an action request to central server 107. The action request message requests one of a 
number of action types during playback session, including pause playback, rewind, fast-forward, user specified 
internal..." (pg. 12 [31]) (See also pg. 14 [40]). 



Applicant, in response filed, relies on paragraph [31] to show the support for the above 
features. 

The paragraph [31] is reproduced here: 

During the playback session (as initiated by start playback requests 221 and 223), any of the active users 
(host user and guest users) can request a playback action, [emphasis added] In order to do so, an active user sends an 
action request (e.g. action request 225) to central server 107. The action request message requests one of a number 
of action types during the playback session, including pause playback, rewind, fast-forward, user-specified internal 
effect algorithm to modify audio or video (e.g. altering the audio and video in order to accentuate a favorite actress), 
or textual comment from a user. 



This paragraph does not show an action request with the playback option. In this 
paragraph, the action request includes actions such as pause, rewind, ff, etc. 

In other words, the option is not equivalent to actions such as rewind, ff, etc., because the 
playback option gives the guest users a permission to request different types of actions. 

Thus, the specification as filed clearly fails to teach, disclose and/or suggest the process 
of receiving an action request from the guest terminal wherein the action request includes the 
playback option and sending the playback option received from the guess wireless terminal 



to the host wireless terminal. 
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At best understood, the specification discloses invite request message, wherein the invite 
message includes the playback option giving the users the permission or enabling the users to 
request different types of actions. 

Hence, the claim(s) contains subject matter which was not described in the specification 
in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the 
time the application was filed, had possession of the claimed invention. 

Claims 2-19, 23-25, 30-33, 36 and 38-41 are rejected for the same reasons as set forth 

above. 
Note: 

• Since the specification fails to define the term "computer readable medium", the 
computer-readable medium is strictly interpreted as hardware/physical storage 
medium. 
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Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

This application currently names joint inventors. In considering patentability of the 
claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various 
claims was commonly owned at the time any inventions covered therein were made absent any 
evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out 
the inventor and invention dates of each claim that was not commonly owned at the time a later 
invention was made in order for the examiner to consider the applicability of 35 U.S.C. 103(c) 
and potential 35 U.S.C. 102(e), (f) or (g) prior art under 35 U.S.C. 103(a). 

2. Claims 1-2, 4-6, 8-19, 23-25, 30-33 and 42-45 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Liou (WO 99/46702) in view of Dalrymple et al. (hereinafter 
Dalrymple, US 6,976,094 Bl), further in view of Handley et al. (hereinafter Handley, RFC 2327: 
SDP, April 1998), and further in view of Vilander (US 7,193,987 B2). 
As per claim 1, Liou discloses a method comprising: 

distributing a start playback request from the host terminal to the guest terminal, wherein 
the start playback request directs the guest terminal to being a playback session of a media file 
that is locally stored in the guest terminal in synchronization with a beginning of the playback 
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session at the host terminal (fig. 10: joining and distributing play request, user 1, user 2, pg. 18 
L4-32, pg. 14 LI 2-32: receiving messages and distributing to clients); 

receiving an action request from the guest terminal, wherein the action request includes 
the playback option (fig. 10: receiving pause action from the terminal, pg. 18 L4 to pg. 19 L13: 
VCR commands); and 

sending the playback option received from the guest terminal to the host terminal (fig. 10: 
sending the pause message). 

However, Liou does not expressly disclose the process of receiving a first media 
playback invite request initiated by a host wireless terminal, the first media playback invite 
request including: information sufficient to identify at least one guest wireless terminal, an 
identification of a pre-existing playable media file, and a playback option enabling the guest 
terminal to request different types of playback actions in connection with playback of the 
identified media file; transmitting a second media playback to the guest wireless terminal 
subsequent to receipt of the first media playback invite request, wherein the media playback 
invite request includes a playback option and the process of relaying a media playback accept 
response from the guest terminal to the host terminal (a typical session set up or initiation 
processes). 

Dahymple explicitly discloses a call set-up method during conferencing comprising the 
process of receiving a first media playback invite request initiated by a host terminal, the first 
media playback invite request including: information sufficient to identify at least one guest 
terminal, an identification of a pre-existing playable media file (fig. 2 step 100: Invite request) 
transmitting a second media playback to the guest wireless terminal subsequent to receipt of the 
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first media playback invite request (fig. 2 item #106) and the process of relaying a media 
playback accept response from the guest terminal to the host terminal (a typical session set up or 
initiation processes, fig. 2 step #100, 106, 108, 110, fig. 4, col. 3 L50 to col. 4 L46, col. 5 L23- 
50: the OK response message in SIP protocol by a node/terminal is to convey to the client that 
the action was successfully received, understood and accepted). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou in view of Dalrymple in order to set-up the session. 

One of ordinary skilled in the art would have been motivated because this would have 
established a communication session between two computers through invitations (Dalrymple: 
col. 3 L50 to col. 4 L21). 

However, Liou in view of Dalrymple does not disclose the media playback invite request 
including a playback option enabling the guest terminal to request different types of actions (the 
feature is obvious in SIP and SDP protocols). 

Handley explicitly discloses a session description protocol (SDP) including the process of 
sending the invitations to the users, wherein the invitations includes various fields comprising a 
playback option field for enabling the guest terminal to request different types of actions, i.e. 
enabling the receiver for interactive conferencing, i.e. for sending the actions (pg. 23: a= 
sendrecv field enables the users to send and receive data). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou and Dalrymple in view of Handley in order to include a 
playback option in the invitation. 
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One of ordinary skilled in the art would have been motivated because this would have 
enabled the receivers, i.e. users, to engage in an interactive conference (Handley: pg. 23). 

However, LIOU, Dalrymple and Handley do not disclose the method wherein the 
terminals are wireless terminals. 

Vilander explicitly discloses setting up communications between wireless terminals using 
the SIP protocols (fig. 4: MS, and col. 4 L20-38). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify LIOU, Dalrymple and Handley in view of Vilander in order to 
enable the wireless devices to engage in a playback session. 

One of ordinary skilled in the art would have been motivated because it would have 
provided playback session to the wireless devices. 

As per claim 2, Liou discloses the method further comprising distributing the action 
request to another terminal during the playback session (pg. 6 L18-27, pg. 14 L12-33: receives 
action(s) and distributes to all session manager associated with the users, fig. 10). 

As per claim 4, Liou discloses the method wherein the action request is selected from the 
group consisting of a rewind request, a pause playback request, a fast forward request, a textual 
comment request, and a user-specified internal effect algorithm to modify audio or video of the 
media file (pg. 11 L21-32, pg. 12 L12-25, fig. 4, fig. 10: pause action). 

As per claim 5, Liou discloses the method comprising distributing a stop playback 
request from the host terminal to the guest terminal in response to the host user terminating the 
playback session (pg. 11 L21-32, pg. 12 Ll-25: a stop button will stop the playback session, pg. 
14 LI 2-32: distributing actions to the rest of the clients). 
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As per claim 6, Liou discloses the method further comprising storing an internal time in 
response to distributing a start playback request from the host terminal to the guest terminal, 
wherein the start playback request directs the guest terminal to being a playback session of a 
media file that is locally stored in the guest terminal in synchronization with the host terminal 
(pg. 7 LI 0-14) and providing an elapsed time since distributing the start playback request to third 
terminal when the third terminal joins the playback session during the playback session (pg. 6 
L3-27: delaying, pg. 14 L12-24). 

As per claim 8, Liou discloses the method further comprising receiving a stop playback 
request from the guest terminal in response to the guest user withdrawing from the playback 
session (pg. 11 L21-32, pg. 12 LI -25: a stop button will stop the playback session); and 
removing a session entry that is associated with the guest terminal, wherein the session entry 
indicates participation of the guest terminal in the playback session (pg. 14 LI 2-23: managing 
state of the conference). 

As per claim 9, Liou discloses the method further comprising receiving a stop playback 
request from the host terminal in response to the host user ending the playback session and 
terminating the playback session in response to receiving a stop playback request (pg. 1 1 L21-32, 
pg. 12 LI -25: a stop button will stop the playback session). 

As per claim 10, Liou discloses the method further comprising instructing the guest 
terminal to modify the media file in accordance with a modification file during the playback 
session (fig. 4, pg. 7 L29 to pg. 8 L6: client loads one of video and recorded annotation file in a 
user interface for performing annotation of the video file, i.e. annotating/modifying the media 
file in accordance with the recorded annotation file, pg. 12 LI 2-25: recording annotations in 
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accordance with a text edit window, pg. 19 L9-13: annotate during the playback of recorded 
annotation file, commanding to draw annotation based on the received annotation record, i.e. a 
modification file). 

As per claim 13, Liou discloses the computer readable medium further comprising 
instructions to perform distributing a stop playback request from the host terminal to the guest 
terminal (fig. 10). 

However, Liou does not disclose distributing a stop playback request to at least one other 
terminal in response to host terminal user terminating the playback session. 

Dalrymple discloses multiple guest terminals and//or users engaging in playback session 
utilizing SIP protocol (col. 4 L31-47). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou in view of Dalrymple in order to distribute the stop 
request to at least one other terminal. 

One of ordinary skilled in the art would have been motivated because it would have 
enabled playback and/or conference session with multiple users (Dalrymple: col. 4 L31-47). 

As per claim 14, Liou discloses a method comprising: 

Distributing/sending a start playback request from the host terminal to the guest terminal, 
wherein the start playback request directs the guest terminal to being a playback session of a 
media file that is locally stored in the guest terminal in synchronization with a beginning of the 
playback session at the host terminal (fig. 10: joining and distributing play request, user 1, user 2, 
pg. 18 L4-32, pg. 14 LI 2-32: receiving messages and distributing to clients); 
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receiving an action request from the guest terminal, wherein the action request includes 
the playback option (fig. 10: receiving pause action from the terminal, pg. 18 L4 to pg. 19 L13: 
VCR commands); and 

sending the playback option received from the guest terminal to the host terminal (fig. 10: 
sending the pause message). 

However, Liou does not expressly disclose the process of sending a media playback 
invite request to at least one guess wireless terminal from a host wireless terminal, wherein the 
media playback invite request includes information sufficient to identify at least one guest 
wireless terminal, an identification of a pre-existing playable media file, and a playback option 
enabling the guest terminal to request different types of playback actions in connection with 
playback of the identified media file and the process of receiving a media playback accept 
response from the guest terminal to the host terminal in response to invite request (a typical 
session set up or initiation processes). 

Dalrymplc explicitly discloses a call set-up method during conferencing comprising the 
process of receiving a first media playback invite request initiated by a host terminal, the first 
media playback invite request including: information sufficient to identify at least one guest 
terminal, an identification of a pre-existing playable media file (fig. 2 step 100: Invite request) 
and the process of receiving a media playback accept response from the guest terminal to the 
host terminal (a typical session set up or initiation processes, fig. 2 step #100, 106, 108, 110, fig. 
4, col. 3 L50 to col. 4 L46, col. 5 L23-50: the OK response message in SIP protocol by a 
node/terminal is to convey to the client that the action was successfully received, understood and 
accepted). 
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Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou in view of Dalrymple in order to set-up the session. 

One of ordinary skilled in the art would have been motivated because this would have 
established a communication session between two computers through invitations (Dalrymple: 
col. 3 L50 to col. 4 L21). 

However, Liou in view of Dalrymple does not disclose the media playback invite request 
including a playback option enabling the guest terminal to request different types of actions (the 
feature is obvious in SIP and SDP protocols). 

Handley explicitly discloses a session description protocol (SDP) including the process of 
sending the invitations to the users, wherein the invitations includes various fields comprising a 
playback option field for enabling the guest terminal to request different types of actions, i.e. 
enabling the receiver for interactive conferencing, i.e. for sending the actions (pg. 23: a= 
sendrecv field enables the users to send and receive data). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou and Dalrymple in view of Handley in order to include a 
playback option in the invitation. 

One of ordinary skilled in the art would have been motivated because this would have 
enabled the receivers, i.e. users, to engage in an interactive conference (Handley: pg. 23). 

However, LIOU, Dalrymple and Handley do not disclose the method wherein the 
terminals are wireless terminals. 

Vilander explicitly discloses setting up communications between wireless terminals using 
the SIP protocols (fig. 4: MS, and col. 4 L20-38). 
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Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify LIOU, Dalrymple and Handley in view of Vilander in order to 
enable the wireless devices to engage in a playback session. 

One of ordinary skilled in the art would have been motivated because it would have 
provided playback session to the wireless devices. 

As per claim 30, Liou discloses the method wherein the media file is locally stored on the 
guest terminal for playback (pg. 6 L3-10). 

As per claim 43, LIOU in view of Dalrymple discloses the apparatus wherein the media 
playback invite request includes information sufficient to identify multiple guest wireless 
terminals (col. 4 L3-46). 

As per claims 11-12, 15-19, 23-25, 31-33, 42 and 44-45, they do not teach or further 
define over the limitations in claims 1-2, 4-6, 8-10, 13, 14 and 30. Therefore, claims 11-12, 15- 
19, 23-25, 31-33, 42 and 44-45 are rejected for the same reasons as set forth in claims 1-2, 4-6, 
8-10, 14 and 30. 

3. Claims 36, 39 and 46-47 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Liou (WO 99/46702) in view of Dalrymple et al. (hereinafter Dalrymple, US 6,976,094 Bl), 
further in view of Kumar et al. (hereinafter Kumar, US 6,006,253), and further in view of 
Vilander (US 7,193,987 B2). 

As per claim 36, Liou discloses an apparatus (i.e. a host and/or guest terminal, pg. 10 Ll- 
24, for use in a synchronous media playback system) comprising: 

a processor (pg. 10 LI -24); and 
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memory (pg. 6 L3-10) storing computer-executable instructions that when executed (pg. 
10 LI -24, fig. 1: plurality of host terminals), perform: 

receiving at the apparatus a start playback request, wherein the start playback request 
begins a playback session of the identified media file in synchronization with a beginning of the 
playback session at a host terminal (fig. 10: joining and distributing play request, user 1, user 2, 
pg. 18 L4-32, pg. 14 LI 2-32: receiving messages and distributing to clients); 

subsequent to receiving the start playback request, transmitting an action request to the 
server, wherein the action request includes the playback option (fig. 10: receiving pause action 
from the terminal, pg. 18 L4 to pg. 19 L13: VCR commands and sending the pause message). 

However, Liou does not expressly disclose the process of receiving a media playback 
invitation at the apparatus from a server via a wireless channel, wherein the media playback 
invitation includes an identification of a pre-existing playable media file, a playback option 
enabling the apparatus to request different types of playback actions in connection with playback 
of the identified media file and responsive to receiving the media playback invitation, 
transmitting a media playback accept response to the server, wherein if the apparatus does not 
have the media file, the apparatus downloads the media file before transmitting the media 
playback accept response. 

Dalrymple explicitly discloses a call set-up method during conferencing comprising the 
process of sending an invite request message from the host terminal to the guest terminal through 
a central server, i.e. receiving at the apparatus an invitation from the server, wherein the 
invitation includes an identification of a pre-existing playable media file (SIP uses SDP to 
describe the session including identification of media file) and responsive to receiving the media 
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playback invitation, transmitting a media playback accept response to the server (i.e. a standard 
approach for setting up a communication session and sending invitations in SIP protocol, fig. 2 
step #100, 106, 108, 110, fig. 4, col. 3 L50 to col. 4 L46, col. 5 L23-50: the OK response 
message in SIP protocol by a node/terminal is to convey to the client that the action was 
successfully received, understood and accepted). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou in view of Dalrymple in order to invite the users and 
receive the response. 

One of ordinary skilled in the art would have been motivated because this would have 
established a communication session between two computers through invitations (Dalrymple: 
col. 3 L50 to col. 4 L21). 

However, Liou in view of Dalrymple does not disclose the media playback invite request 
including a playback option enabling the guest terminal to request different types of actions and 
the process wherein if the apparatus does not have the media file, the apparatus downloads the 
media file before transmitting the media playback accept response. 

Kumar discloses the SDP comprising sending an announcement, i.e. invitations, 
including a playback option, i.e. field for indicating mode of operation such as sendonly, 
sendrecv or recvonly, enabling the guest terminal to request different types of actions i.e. 
enabling the receiver for interactive conferencing, i.e. for sending the actions (fig. 6 item #650, 
col. 10 LI 1-44), and the process of downloading the media file if the apparatus does not have the 
media file (col. 7 L25-55: note that the invitations and/or announcement enables the user to 
download the slides before and/or after the user transmits the accept response). 
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Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou and Dalrymple in view of Kumar in order to include a 
playback option in the invitation and download the media filed before transmitting the accept 
message. 

One of ordinary skilled in the art would have been motivated because this would have 
enabled the receivers, i.e. users, to engage in an interactive conference regarding the media file. 

However, LIOU, Dalrymple and Handley do not disclose the process of receiving a 
media playback invitation at the apparatus from a server via a wireless channel. 

Vilander explicitly discloses the process of receiving a media playback invitation at the 
apparatus from a server via a wireless channel (fig. 4: MS, and col. 3 L65 to col. 4 L38). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify LIOU, Dalrymple and Handley in view of Vilander in order to 
receive the invitation from the server via the wireless channel. 

One of ordinary skilled in the art would have been motivated because it would have 
provided playback session to the wireless devices. 

As per claim 38, Liou and Dalrymple discloses the apparatus wherein the processor 
utilizes the communication interface to communicate to a central server, wherein the central 
server receives and forwards invitations and responses between the apparatus and the terminal 
(Liou: pg. 10 Ll-24, pg. 14 L12-32, fig. 1, fig. 10; Dalrymple: fig. 2-4, pg. 16 L21-27). 

As per claim 39, Liou discloses the apparatus wherein the processor includes instructions 
to perform modifying the media file in accordance with a modification file during the playback 
session (fig. 4, pg. 7 L29 to pg. 8 L6: client loads one of video and recorded annotation file in a 
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user interface for performing annotation of the video file, i.e. annotating/modifying the media 
file in accordance with the recorded annotation file, pg. 12 LI 2-25: recording annotations in 
accordance with a text edit window, pg. 19 L9-13: annotate during the playback of recorded 
annotation file, commanding to draw annotation based on the received annotation record, i.e. a 
modification file). 

As per claims 46-47, they do not teach or further define over the limitations in claims 36 
and 39. Therefore claims 46-47 are rejected for the same reasons as set forth in claims 36 and 39. 

4. Claim 40 is rejected under 35 U.S.C. 103(a) as being unpatentable over Liou (WO 
99/46702) in view of Dalrymple et al. (hereinafter Dalrymple, US 6,976,094 Bl), and further in 
view of Handley et al. (hereinafter Handley, RFC 2327: SDP, April 1998), further in view of 
Vilander (US 7,193,987 B2), and further in view of Kumar et al. (hereinafter Kumar, US 
6,006,253). 

As per claim 40, Liou, Dalrymple, Handley and Vilander discloses the method as in 
claim 1 as set forth above. 

However, Liou, Dalrymple, Handley and Vilander do not disclose the method wherein if 
the guest terminal does not have the media file, the guest terminal downloads the media file 
before sending the media playback accept response. 

Kumar discloses the process of downloading the media file if the apparatus does not have 
the media file (col. 7 L25-55: note that the invitations and/or announcement enables the user to 
download the slides before and/or after the user transmits the accept response). 
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Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou, Dalrymple, Handley and Vilander in view of Kumar in 
order to download the media filed before transmitting the accept message. 

One of ordinary skilled in the art would have been motivated because it would have 
enabled the receivers, i.e. users, to engage in an interactive conference regarding the media file. 

5. Claim 7 is rejected under 35 U.S.C. 103(a) as being unpatentable over Liou (WO 
99/46702) in view of Dalrymple et al. (hereinafter Dalrymple, US 6,976,094 Bl), in view of 
Handley et al. (hereinafter Handley, RFC 2327: SDP, April 1998), further in view of Vilander 
(US 7,193,987 B2), and further in view of Crandall et al. (hereinafter Crandall, US 
2002/0107040 A 1). 

As per claim 7, Liou, Dalrymple, Handley and Vilander discloses the process of receiving 
a host internal time from the host terminal or the guest terminal, wherein the host internal time is 
derived from a global time (Liou: pg. 6 L3-27, pg. 14 L12-24, pg. 7 L10-14). 

However, Liou, Dalrymple, Handley and Vilander do not expressly disclose the process 
of comparing the host internal time to a guest internal time in order to derive a time difference, 
wherein the guest internal time is derived from the global time; and adjusting transmission of a 
subsequent message to the host terminal or the guest terminal (Liou may inherently teach the 
process). 

Crandall discloses the process of synchronizing messages by determining host time and 
guest time, comparing the host time with the guest time in order to derive time difference, i.e. 
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delay, and adjusting the transmission of a subsequent message to the host terminal (fig. 4, fig. 5, 
fig. 7, fig. 9, pg. 2 [0030-0034], pg. 3 [0044-0046], pg. 4 [0047-0057]). 

Therefore it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou, Dalrymple, Handley and Vialnder in view of Crandall in 
order to derive a time difference and adjust the transmission of the messages. 

One of ordinary skilled in the art would have been motivated because it would have 
provided same amount of latency for different users and/or actions (Crandall, pg. 1 [0005]). 

6. Claims 3 and 41 are rejected under 35 U.S.C. 103(a) as being unpatentable over Liou 
(WO 99/46702) in view of Dalrymple et al. (hereinafter Dalrymple, US 6,976,094 Bl), in view 
of Handley et al. (hereinafter Handley, RFC 2327: SDP, April 1998), further in view of Vilander 
(US 7,193,987 B2), and further in view of Agresta et al. (hereinafter Agresta, US 2002/0091848 
Al). 

As per claim 3, Liou, Dalrymple, Handley and Vilander do not disclose the process of 
verifying permissions associated with the guest terminal, wherein the sending of the playback 
option received from the guest terminal to the host terminal is responsive to verifying the 
permissions associated with the guest terminal. 

Agresta explicitly teaches the process of verifying the permissions, i.e. authoring account 
before executing the process such as pause, rewind, forward, etc. (fig. 4A step #116, 138, pg. 6 
[0051]). 
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Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou, Dalrymple, Handley and Vilander in view of Agresta in 
order to verify the permissions of the terminals and/or users before executing any actions. 

One of ordinary skilled in the art would have been motivated because it would have 
verified the access rights of the user. 

As per claim 41, it does not teach or further define over the limitations in claims 3 and 
20. Therefore, claim 41 is rejected for the same reasons as set forth in claims 3 and 20. 

Additional References 
The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

• Andreakis et al., US 6,816,895 B2: Updating the capability negotiation 
information of a mobile station with an editing application downloaded from 
service provider. 

• Saxena et al., U. S. Patent No. 5,805,821. 

• Agarwal et al, U. S. Patent No. 6,314,466 Bl. 

• Schmidt et al, U.S. Patent No. 6,353,174 Bl. 

• King et al, US 5,600,775: Method and apparatus for annotating full motion video. 

• MeLampy et al, US 7,133,923 B2: Real-Time Transport protocol. 
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Conclusion 

Examiner's Remarks: The teachings of the prior art should not be restricted and/or 
limited to the citations by columns and line numbers, as specified in the rejection. Although the 
specified citations are representative of the teachings of the art and are applied to specific 
limitations within the individual claim, other passages and figures may apply as well. It is 
respectfully requested from the applicant in preparing responses, to fully consider the references 
in its entirety as potentially teaching all or part of the claimed invention, as well as the context of 
the passage as taught by the prior art or disclosed by the examiner. 

In the case of amendments, Applicant is respectfully requested to indicate the portion(s) 
of the specification which dictate(s) the structure relied on for proper interpretation and support, 
for ascertaining the metes and bounds of the claimed invention. 

Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to KAMAL B. DIVECHA whose telephone number is (571)272- 
5863. The examiner can normally be reached on Increased Flex Work Schedule. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Follansbee can be reached on 571-272-3964. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from cither Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



Kamal Divecha 
Art Unit 2451 

/John Follansbee/ 

Supervisory Patent Examiner, Art Unit 245 1 



